Annotate hardware config module parameters in drivers/tty/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/tty/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Jiri Slaby <jslaby@suse.com>
cc: linux-serial@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0031-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/staging/vme/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/vme/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Martyn Welch <martyn@welchs.me.uk>
cc: Manohar Vanga <manohar.vanga@gmail.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0030-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/staging/speakup/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/speakup/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: speakup@linux-speakup.org
cc: devel@driverdev.osuosl.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0029-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/staging/media/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/media/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-media@vger.kernel.org
cc: devel@driverdev.osuosl.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0028-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/scsi/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/scsi/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Juergen E. Fischer" <fischer@norbit.de>
cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
cc: "Martin K. Petersen" <martin.petersen@oracle.com>
cc: Dario Ballabio <ballabio_dario@emc.com>
cc: Finn Thain <fthain@telegraphics.com.au>
cc: Michael Schmitz <schmitzmic@gmail.com>
cc: Achim Leubner <achim_leubner@adaptec.com>
cc: linux-scsi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0027-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/pcmcia/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/pcmcia/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0026-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/pci/hotplug/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/pci/hotplug/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
cc: Scott Murray <scott@spiteful.org>
cc: linux-pci@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0025-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/parport/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/parport/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0024-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/wireless/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/wireless/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Kalle Valo <kvalo@codeaurora.org>
cc: linux-wireless@vger.kernel.org
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0023-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/wan/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/wan/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Jan \"Yenya\" Kasprzak" <kas@fi.muni.cz>
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0022-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/irda/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/irda/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Samuel Ortiz <samuel@sortiz.org>
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0021-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/hamradio/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/hamradio/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Thomas Sailer <t.sailer@alumni.ethz.ch>
cc: Joerg Reuter <jreuter@yaina.de>
cc: linux-hams@vger.kernel.org
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0020-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/ethernet/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/ethernet/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
cc: Jaroslav Kysela <perex@perex.cz>
cc: netdev@vger.kernel.org
cc: linux-parisc@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0019-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/can/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/can/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
cc: Wolfgang Grandegger <wg@grandegger.com>
cc: linux-can@vger.kernel.org
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0018-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/arcnet/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/arcnet/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0017-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/net/appletalk/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/net/appletalk/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
cc: netdev@vger.kernel.org
[bwh: Drop changes to cops driver, which we removed]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0016-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/mmc/host/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/mmc/host/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Pierre Ossman <pierre@ossman.eu>
cc: Ulf Hansson <ulf.hansson@linaro.org>
cc: linux-mmc@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0015-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/misc/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/misc/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0014-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/media/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/media/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: mjpeg-users@lists.sourceforge.net
cc: linux-media@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0013-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/isdn/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/isdn/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Karsten Keil <isdn@linux-pingi.de>
cc: netdev@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0012-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/input/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/input/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
cc: linux-input@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0011-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/iio/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/iio/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
cc: linux-iio@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0010-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/i2c/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/i2c/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wolfram Sang <wsa@the-dreams.de>
cc: Jean Delvare <jdelvare@suse.com>
cc: linux-i2c@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0009-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/gpio/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/gpio/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
cc: Alexandre Courbot <gnurou@gmail.com>
cc: linux-gpio@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0008-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/cpufreq/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/cpufreq/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
cc: Viresh Kumar <viresh.kumar@linaro.org>
cc: linux-pm@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0007-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/clocksource/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/clocksource/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Daniel Lezcano <daniel.lezcano@linaro.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: linux-kernel@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0006-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/char/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/char/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0005-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/char/mwave/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/char/mwave/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0004-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in drivers/char/ipmi/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/char/ipmi/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Corey Minyard <cminyard@mvista.com>
cc: openipmi-developer@lists.sourceforge.net

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0003-Annotate-hardware-config-module-parameters-in-driver.patch

Annotate hardware config module parameters in arch/x86/mm/

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in arch/x86/mm/.

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org
cc: linux-kernel@vger.kernel.org
cc: nouveau@lists.freedesktop.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0002-Annotate-hardware-config-module-parameters-in-arch-x.patch

Annotate module params that specify hardware parameters (eg. ioport)

Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).

This will enable such parameters to be locked down in the core parameter
parser for secure boot support.

I've also included annotations as to what sort of hardware configuration
each module is dealing with for future use.  Some of these are
straightforward (ioport, iomem, irq, dma), but there are also:

 (1) drivers that switch the semantics of a parameter between ioport and
     iomem depending on a second parameter,

 (2) drivers that appear to reserve a CPU memory buffer at a fixed address,

 (3) other parameters, such as bus types and irq selection bitmasks.

For the moment, the hardware configuration type isn't actually stored,
though its validity is checked.

Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0001-Annotate-module-params-that-specify-hardware-paramet.patch

Kbuild.include: addtree: Remove quotes before matching path

systemtap currently fails to build modules when the kernel source and
object trees are separate.

systemtap adds something like -I"/usr/share/systemtap/runtime" to
EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
absolute directory.  But since make has no understanding of shell
quoting, it does anyway.

For a long time this didn't matter, because addtree would still emit
the original -I option after the adjusted one.  However, commit
db547ef19064 ("Kbuild: don't add obj tree in additional includes")
changed it to remove the original -I option.

Remove quotes (both double and single) before matching against the
excluded patterns.

References: https://bugs.debian.org/856474
Reported-by: Jack Henschel <jackdev@mailbox.org>
Reported-by: Ritesh Raj Sarraf <rrs@debian.org>
Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-include-addtree-remove-quotes-before-matching-path.patch

Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG.  This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver.  Enabling it should not
force usb_common to be built-in!

Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-usb-kconfig-using-select-for-usb_co.patch

kbuild: Do not use hyphen in exported variable name

This definition in Makefile.dtbinst:

    export dtbinst-root ?= $(obj)

should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories.  However, the
variable does not reliably get exported to the environment, perhaps
because its name contains a hyphen.

Rename the variable to dtbinst_root.

References: https://bugs.debian.org/833561
Fixes: 323a028d39cdi ("dts, kbuild: Implement support for dtb vendor subdirs")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-do-not-use-hyphen-in-exported-variable-name.patch

fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full
dependencies of a module.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name fs-add-module_softdep-declarations-for-hard-coded-cr.patch

phy/marvell: disable 4-port phys

The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.

[bwh: Also #if-out the init functions for these PHYs to avoid
 compiler warnings]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch

kbuild: Use -nostdinc in compile tests

gcc 4.8 and later include <stdc-predef.h> by default.  In some
versions of eglibc that includes <bits/predefs.h>, but that may be
missing when building with a biarch compiler.  Also <stdc-predef.h>
itself could be missing as we are only trying to build a kernel, not
userland.

The -nostdinc option disables this, though it isn't explicitly
documented.  This option is already used when actually building
the kernel, but not by cc-option and other tests.  This can result
in silently miscompiling the kernel.

References: https://bugs.debian.org/717557
References: https://bugs.debian.org/726861
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron

Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-veyro.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly

Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-firef.patch

ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som

Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform.  Tested on a Radxa Rock2 Square board.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-rock2.patch

ARM: dts: rockchip: add ARM Mali GPU node for rk3288

Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-add-arm-mali-gpu-node-for-rk3288.patch

dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.

Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:

  https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz

Remove the copyright and GPL licence header as deemed not necessary.

Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and add vendor specific ones.

Drop the "clock-names" property as the Mali Midgard GPU uses only one
clock (the driver now needs to call clk_get with NULL).

Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".

Replace the deprecated "operating-points" optional property with
"operating-points-v2".

Omit the following optional properties in this initial version as they
are only used in very specific cases:

  * snoop_enable_smc
  * snoop_disable_smc
  * jm_config
  * power_model
  * system-coherency
  * ipa-model

Update the example accordingly to reflect all these changes, based on
rk3288 mali-t760.

CC: John Reitan <john.reitan@arm.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name dt-bindings-gpu-add-bindings-for-the-arm-mali-midgar.patch

x86: Make x32 syscall support conditional on a kernel parameter

Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).

Still, adding another flavour just to turn on x32 seems wasteful.  And
the only differences on syscall entry are two instructions (mask out
the x32 flag and compare the syscall number).

So pad the standard comparison with a nop and add a kernel parameter
"syscall.x32" which controls whether this is replaced with the x32
version at boot time.  Add a Kconfig parameter to set the default.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch

x86: memtest: WARN if bad RAM found

Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch

MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition

Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch

MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only

Commit c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.

Note: this should be replace by upstream fix when available.

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch

platform/x86: ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun <yjx@flygoat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-several-models-to-no.patch

platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch

platform/x86: ideapad-laptop: Add Y720-15IKBN to no_hw_rfkill

Lenovo Legion Y720-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y720-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill

Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y520-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add IdeaPad V310-15ISK to no_hw_rfkill

Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v310-15isk-t.patch

platform/x86: ideapad-laptop: Add IdeaPad 310-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad 310-15IKB does not have an hw rfkill
switch. This results in hard-blocked radios after boot, resulting in
always blocked radios rendering them unusable.

Add the IdeaPad 310-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Rebhan <Sven.Rebhan@googlemail.com>
[andy: massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-310-15ikb-to.patch

pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems

It turns out there are quite many Chromebooks out there that have the
same keyboard issue than Acer Chromebook. All of them are based on
Intel_Strago reference and report their DMI_PRODUCT_FAMILY as
"Intel_Strago" (Samsung Chromebook 3 and Cyan Chromebooks are exceptions
for which we add separate entries).

Instead of adding each machine to the quirk table, we use
DMI_PRODUCT_FAMILY of "Intel_Strago" that hopefully covers most of the
machines out there currently.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
Suggested: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name pinctrl-cherryview-extend-the-chromebook-dmi-quirk-t.patch

firmware: dmi: Add DMI_PRODUCT_FAMILY identification string

Sometimes it is more convenient to be able to match a whole family of
products, like in case of bunch of Chromebooks based on Intel_Strago to
apply a driver quirk instead of quirking each machine one-by-one.

This adds support for DMI_PRODUCT_FAMILY identification string and also
exports it to the userspace through sysfs attribute just like the
existing ones.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name firmware-dmi-add-dmi_product_family-identification-s.patch

ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch

Don't WARN about expected W+X pages on Xen

Currently Xen PV domains (or at least dom0) on amd64 tend to have a
large number of low kernel pages with W+X permissions.  It's not
obvious how to fix this, and we're not going to get any new
information by WARNing about this, but we do still want to hear about
other W+X cases.  So add a condition to the WARN_ON.

Gbp-Pq: Topic debian
Gbp-Pq: Name amd64-don-t-warn-about-expected-w+x-pages-on-xen.patch

btrfs: warn about RAID5/6 being experimental at mount time

Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]

Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch

fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS

Various free and proprietary AV products use this feature and users
apparently want it.  But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that.  So warn and taint the kernel if this feature is
actually used.

Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch

fjes: Disable auto-loading

fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device.  Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.

Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

security,perf: Allow further restriction of perf_event_open

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

dccp: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch

af_802154: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch

aufs4.11.7+ standalone patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ standalone patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-standalone.patch

aufs4.11.7+ mmap patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ mmap patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-mmap.patch

aufs4.11.7+ base patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.11.7+ base patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-base.patch

radeon: Firmware is required for DRM and KMS on R600 onward

radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.

radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.

Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it is
missing, except for the pre-R600 case.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

firmware: Remove redundant log messages from drivers

Now that firmware_class logs every success and failure consistently,
many other log messages can be removed from drivers.

This will probably need to be split up into multiple patches prior to
upstream submission.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware-remove-redundant-log-messages-from-drivers.patch

firmware_class: Log every success and failure against given device

The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures.  They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that.  Therefore, add specific log messages for the failure modes that
aren't currently logged.

In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise.  Therefore, also log successes.

This makes many error messages in drivers redundant, which will be
removed in later patches.

This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).

NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch

iwlwifi: Do not request unreleased firmware for IWL6000

The iwlwifi driver currently supports firmware API versions 4-6 for
these devices.  It will request the file for the latest supported
version and then fall back to earlier versions.  However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.

The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless.  So stop
requesting the unreleased firmware.

Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch

af9005: Use request_firmware() to load register init script

Read the register init script from the Windows driver.  This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.

Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch

Install perf scripts non-executable

[bwh: Forward-ported to 3.12]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-install.patch

Create manpages and binaries including the version

[bwh: Fix version insertion in perf man page cross-references and perf
man page title.  Install bash_completion script for perf with a
version-dependent name.  And do the same for trace.]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch

modpost symbol prefix setting

[bwh: The original version of this was added by Bastian Blank.  The
upstream code includes <generated/autoconf.h> so that <linux/export.h>
can tell whether C symbols have an underscore prefix.  Since we build
modpost separately from the kernel, <generated/autoconf.h> won't exist.
However, no Debian Linux architecture uses the symbol prefix, so we
can simply omit it.]

Gbp-Pq: Topic debian
Gbp-Pq: Name modpost-symbol-prefix.patch

Kbuild: kconfig: Verbose version of --listnewconfig

If the KBUILD_VERBOSE environment variable is set to non-zero, show
the default values of new symbols and not just their names.

Based on work by Bastian Blank <waldi@debian.org> and
maximilian attems <max@stro.at>.  Simplified by Michal Marek
<mmarek@suse.cz>.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name Kbuild-kconfig-Verbose-version-of-listnewconfig.patch

powerpcspe-omit-uimage

Gbp-Pq: Topic debian
Gbp-Pq: Name powerpcspe-omit-uimage.patch

Fix uImage build

[bwh: This was added without a description, but I think it is dealing
with a similar issue to powerpcspe-omit-uimage.patch]

Gbp-Pq: Topic debian
Gbp-Pq: Name arch-sh4-fix-uimage-build.patch

Partially revert "MIPS: Add -Werror to arch/mips/Kbuild"

This reverts commit 66f9ba101f54bda63ab1db97f9e9e94763d0651b.

We really don't want to add -Werror anywhere.

Gbp-Pq: Topic debian
Gbp-Pq: Name mips-disable-werror.patch

Tweak gitignore for Debian pkg-kernel using git svn.

[bwh: Tweak further for pure git]

Gbp-Pq: Topic debian
Gbp-Pq: Name gitignore.patch

kbuild: Make the toolchain variables easily overwritable

Allow make variables to be overridden for each flavour by a file in
the build tree, .kernelvariables.

We currently use this for ARCH, KERNELRELEASE, CC, and in some cases
also CROSS_COMPILE, CFLAGS_KERNEL and CFLAGS_MODULE.

This file can only be read after we establish the build tree, and all
use of $(ARCH) needs to be moved after this.

Gbp-Pq: Topic debian
Gbp-Pq: Name kernelvariables.patch

Make mkcompile_h accept an alternate timestamp string

We want to include the Debian version in the utsname::version string
instead of a full timestamp string.  However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.

Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.

Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch

Include package version along with kernel release in stack traces

For distribution binary packages we assume
$DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION
are set.

Gbp-Pq: Topic debian
Gbp-Pq: Name version.patch

linux (4.11.11-1) unstable; urgency=medium

  * New upstream stable update:
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.7
    - fs: pass on flags in compat_writev
    - configfs: Fix race between create_link and configfs_rmdir
    - can: gs_usb: fix memory leak in gs_cmd_reset()
    - ila_xlat: add missing hash secret initialization
    - cpufreq: conservative: Allow down_threshold to take values from 1 to 10
    - vb2: Fix an off by one error in 'vb2_plane_vaddr'
    - cec: race fix: don't return -ENONET in cec_receive()
    - selinux: fix double free in selinux_parse_opts_str()
    - mac80211: don't look at the PM bit of BAR frames
    - mac80211/wpa: use constant time memory comparison for MACs
    - [x86] drm/amdgpu: Fix overflow of watermark calcs at > 4k resolutions.
    - [x86] drm/i915: Fix GVT-g PVINFO version compatibility check
    - [x86] drm/i915: Fix scaling check for 90/270 degree plane rotation
    - [x86] drm/i915: Do not sync RCU during shrinking
    - mac80211: fix IBSS presp allocation size
    - mac80211: strictly check mesh address extension mode
    - mac80211: fix dropped counter in multiqueue RX
    - mac80211: don't send SMPS action frame in AP mode when not needed
    - [arm64, armhf] drm/vc4: Fix OOPSes from trying to cache a partially
      constructed BO.
    - serial: 8250_lpss: Unconditionally set PCI master for Quark
    - [sh4] serial: sh-sci: Fix (AUTO)RTS in sci_init_pins()
    - [sh4] serial: sh-sci: Fix late enablement of AUTORTS
    - [x86] mm/32: Set the '__vmalloc_start_set' flag in initmem_init()
    - [armhf] mfd: axp20x: Add support for dts property "xpowers,master-mode"
    - [armhf] dt-bindings: mfd: axp20x: Add "xpowers,master-mode" property for
      AXP806 PMICs
    - [powerpc] mm: Add physical address to Linux page table dump
    - staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data()
    - [armhf] iio: adc: ti_am335x_adc: allocating too much in probe
    - [x86] ALSA: hda: Add Geminilake id to SKL_PLUS
    - ALSA: usb-audio: fix Amanero Combo384 quirk on big-endian hosts
    - USB: hub: fix SS max number of ports
    - usb: core: fix potential memory leak in error path during hcd creation
    - [x86] USB: usbip: fix nonconforming hub descriptor
    - [arm64, armhf] usb: dwc3: gadget: Fix ISO transfer performance
    - pvrusb2: reduce stack usage pvr2_eeprom_analyze()
    - USB: gadget: dummy_hcd: fix hub-descriptor removable fields
    - coda: restore original firmware locations
    - usb: xhci: Fix USB 3.1 supported protocol parsing
    - usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
    - USB: gadget: fix GPF in gadgetfs
    - USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
    - mm/memory-failure.c: use compound_head() flags for huge pages
    - swap: cond_resched in swap_cgroup_prepare()
    - mm: numa: avoid waiting on freed migrated pages
    - userfaultfd: shmem: handle coredumping in handle_userfault()
    - sched/core: Idle_task_exit() shouldn't use switch_mm_irqs_off()
    - genirq: Release resources in __setup_irq() error path
    - alarmtimer: Prevent overflow of relative timers
    - alarmtimer: Rate limit periodic intervals
    - virtio_balloon: disable VIOMMU support
    - [mips*] Fix bnezc/jialc return address calculation
    - [mips*] .its targets depend on vmlinux
    - [sparc*] crypto: Work around deallocated stack frame reference gcc bug
      on sparc.
    - [armhf] dts: am335x-sl50: Fix card detect pin for mmc1
    - [armhf] dts: am335x-sl50: Fix cannot claim requested pins for spi0
    - mm: larger stack guard gap, between vmas
    - Allow stack to grow up to address space limit
    - mm: fix new crash in unmapped_area_topdown()
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.8
    - [armhf] clk: sunxi-ng: a31: Correct lcd1-ch1 clock register offset
    - [armhf] clk: sunxi-ng: v3s: Fix usb otg device reset bit
    - [armhf] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
    - xen/blkback: fix disconnect while I/Os in flight
    - xen-blkback: don't leak stack data via response ring (XSA-216,
      CVE-2017-10911)
    - ALSA: firewire-lib: Fix stall of process context at packet error
    - ALSA: pcm: Don't treat NULL chmap as a fatal error
    - ALSA: hda - Add Coffelake PCI ID
    - ALSA: hda - Apply quirks to Broxton-T, too
    - fs/exec.c: account for argv/envp pointers (CVE-2017-1000365)
    - [powerpc] perf: Fix oops when kthread execs user process
    - autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
    - fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
    - lib/cmdline.c: fix get_options() overflow while parsing ranges
    - [x86] perf/x86/intel: Add 1G DTLB load/store miss support for SKL
    - perf probe: Fix probe definition for inlined functions
    - [x86] KVM: fix singlestepping over syscall (CVE-2017-7518)
    - [s390x] KVM gaccess: fix real-space designation asce handling for gmap
      shadows
    - [powerpc*] KVM: Book3S HV: Cope with host using large decrementer mode
    - [powerpc*] KVM: Book3S HV: Preserve userspace HTM state properly
    - [powerpc*] KVM: Book3S HV: Ignore timebase offset on POWER9 DD1
    - [powerpc*] KVM: Book3S HV: Context-switch EBB registers properly
    - [powerpc*] KVM: Book3S HV: Restore critical SPRs to host values on guest
      exit
    - [powerpc*] KVM: Book3S HV: Save/restore host values of debug registers
    - CIFS: Improve readdir verbosity
    - CIFS: Fix some return values in case of error in 'crypt_message'
    - cxgb4: notify uP to route ctrlq compl to rdma rspq
    - HID: Add quirk for Dell PIXART OEM mouse
    - random: silence compiler warnings and fix race
    - signal: Only reschedule timers on signals timers have sent
    - [powerpc] kprobes: Pause function_graph tracing during jprobes handling
    - ]powerpc*] 64s: Handle data breakpoints in Radix mode
    - Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
    - brcmfmac: add parameter to pass error code in firmware callback
    - brcmfmac: use firmware callback upon failure to load
    - brcmfmac: unbind all devices upon failure in firmware callback
    - time: Fix clock->read(clock) race around clocksource changes
    - time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
    - [arm64] vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW
    - target: Fix kref->refcount underflow in transport_cmd_finish_abort
    - iscsi-target: Fix delayed logout processing greater than
      SECONDS_FOR_LOGOUT_COMP
    - iscsi-target: Reject immediate data underflow larger than SCSI transfer
      length
    - drm/radeon: add a PX quirk for another K53TK variant
    - drm/radeon: add a quirk for Toshiba Satellite L20-183
    - [x86] drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
    - [x86] drm/amdgpu: adjust default display clock
    - [x86] drm/amdgpu: add Polaris12 DID
    - ACPI / scan: Apply default enumeration to devices with ACPI drivers
    - ACPI / scan: Fix enumeration for special SPI and I2C devices
    - rxrpc: Fix several cases where a padded len isn't checked in ticket
      decode (CVE-2017-7482)
    - drm: Fix GETCONNECTOR regression
    - usb: gadget: f_fs: avoid out of bounds access on comp_desc
    - spi: double time out tolerance
    - net: phy: fix marvell phy status reading
    - netfilter: xtables: zero padding in data_to_user
    - netfilter: xtables: fix build failure from COMPAT_XT_ALIGN outside
      CONFIG_COMPAT
    - brcmfmac: fix uninitialized warning in brcmf_usb_probe_phase2()
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.9
    - net: don't call strlen on non-terminated string in dev_set_alias()
    - net: Fix inconsistent teardown and release of private netdev state.
    - [s390x] net: fix up for "Fix inconsistent teardown and release of
      private netdev state"
    - mac80211: free netdev on dev_alloc_name() error
    - decnet: dn_rtmsg: Improve input length sanitization in
      dnrmg_receive_user_skb
    - net: Zero ifla_vf_info in rtnl_fill_vfinfo()
    - net: ipv6: Release route when device is unregistering
    - net: vrf: Make add_fib_rules per network namespace flag
    - af_unix: Add sockaddr length checks before accessing sa_family in bind
      and connect handlers
    - Fix an intermittent pr_emerg warning about lo becoming free.
    - sctp: disable BH in sctp_for_each_endpoint
    - net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
    - net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
    - net/mlx5: Remove several module events out of ethtool stats
    - net/mlx5e: Added BW check for DIM decision mechanism
    - net/mlx5e: Fix wrong indications in DIM due to counter wraparound
    - net/mlx5: Enable 4K UAR only when page size is bigger than 4K
    - proc: snmp6: Use correct type in memset
    - igmp: acquire pmc lock for ip_mc_clear_src()
    - igmp: add a missing spin_lock_init()
    - qmi_wwan: new Telewell and Sierra device IDs
    - net: don't global ICMP rate limit packets originating from loopback
    - ipv6: fix calling in6_ifa_hold incorrectly for dad work
    - sctp: return next obj by passing pos + 1 into sctp_transport_get_idx
    - net/mlx5e: Fix min inline value for VF rep SQs
    - net/mlx5e: Avoid doing a cleanup call if the profile doesn't have it
    - net/mlx5: Wait for FW readiness before initializing command interface
    - net/mlx5e: Fix timestamping capabilities reporting
    - decnet: always not take dst->__refcnt when inserting dst into hash table
    - net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
    - ipv6: Do not leak throw route references
    - rtnetlink: add IFLA_GROUP to ifla_policy
    - netfilter: synproxy: fix conntrackd interaction
    - NFSv4.x/callback: Create the callback service through svc_create_pooled
    - xen/blkback: don't use xen_blkif_get() in xen-blkback kthread
    - [mips*] head: Reorder instructions missing a delay slot
    - [mips*] Avoid accidental raw backtrace
    - [mips*] pm-cps: Drop manual cache-line alignment of ready_count
    - [mips*] Fix IRQ tracing & lockdep when rescheduling
    - ALSA: hda - Fix endless loop of codec configure
    - ALSA: hda - set input_path bitmap to zero after moving it to new place
    - NFSv4.2: Don't send mode again in post-EXCLUSIVE4_1 SETATTR with umask
    - NFSv4.1: Fix a race in nfs4_proc_layoutget
    - Revert "NFS: nfs_rename() handle -ERESTARTSYS dentry left behind"
    - ovl: copy-up: don't unlock between lookup and link
    - gpiolib: fix filtering out unwanted events
    - [x86] intel_rdt: Fix memory leak on mount failure
    - [x86] perf/x86/intel/uncore: Fix wrong box pointer check
    - [x86] drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
    - dm thin: do not queue freed thin mapping for next stage processing
    - [x86] mm: Fix boot crash caused by incorrect loop count calculation in
      sync_global_pgds()
    - [arm64] pinctrl/amd: Use regular interrupt instead of chained
    - mm/vmalloc.c: huge-vmap: fail gracefully on unexpected huge vmap
      mappings
    - xen/blkback: don't free be structure too early
    - xfrm6: Fix IPv6 payload_len in xfrm6_transport_finish
    - xfrm: move xfrm_garbage_collect out of xfrm_policy_flush
    - xfrm: fix stack access out of bounds with CONFIG_XFRM_SUB_POLICY
    - xfrm: NULL dereference on allocation failure
    - xfrm: Oops on error in pfkey_msg2xfrm_state()
    - [arm64] PCI: Fix struct acpi_pci_root_ops allocation failure path
    - [arm64] ACPI: Fix BAD_MADT_GICC_ENTRY() macro implementation
    - [arm*] 8685/1: ensure memblock-limit is pmd-aligned
    - [arm*] davinci: PM: Free resources in error handling path in
      'davinci_pm_init'
    - [arm*] davinci: PM: Do not free useful resources in normal path in
      'davinci_pm_init'
    - Revert "x86/entry: Fix the end of the stack for newly forked tasks"
    - [x86] boot/KASLR: Fix kexec crash due to 'virt_addr' calculation bug
    - [x86] perf: Fix spurious NMI with PEBS Load Latency event
    - [x86] mpx: Correctly report do_mpx_bt_fault() failures to user-space
    - [x86] mm: Fix flush_tlb_page() on Xen
    - ocfs2: o2hb: revert hb threshold to keep compatible
    - ocfs2: fix deadlock caused by recursive locking in xattr
    - iommu/dma: Don't reserve PCI I/O windows
    - [amd64] iommu/amd: Fix incorrect error handling in
      amd_iommu_bind_pasid()
    - [amd64] iommu/amd: Fix interrupt remapping when disable guest_mode
    - mtd: nand: brcmnand: Check flash #WP pin status before nand
      erase/program
    - mtd: nand: fsmc: fix NAND width handling
    - [x86] KVM: fix emulation of RSM and IRET instructions
    - [x86] KVM: vPMU: fix undefined shift in intel_pmu_refresh()
    - [x86] KVM: zero base3 of unusable segments
    - KVM: nVMX: Fix exception injection
    - esp4: Fix udpencap for local TCP packets.
    - [armhf] hsi: Fix build regression due to netdev destructor fix.
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.10
    - fs: completely ignore unknown open flags
    - driver core: platform: fix race condition with driver_override
    - RDMA/uverbs: Check port number supplied by user verbs cmds
    - ceph: choose readdir frag based on previous readdir reply
    - tracing/kprobes: Allow to create probe with a module name starting with a
      digit
    - drm/virtio: don't leak bo on drm_gem_object_init failure (CVE-2017-10810)
    - usb: dwc3: replace %p with %pK
    - Add USB quirk for HVR-950q to avoid intermittent device resets
    - usb: usbip: set buffer pointers to NULL after free
    - usb: Fix typo in the definition of Endpoint[out]Request
    - USB: core: fix device node leak
    - [armhf] pinctrl: meson: meson8b: fix the NAND DQS pins
    - [armhf,arm64] pinctrl: sunxi: Fix SPDIF function name for A83T
    - pinctrl: core: Fix warning by removing bogus code
    - [x86] xhci: Limit USB2 port wake support for AMD Promontory hosts
    - gfs2: Fix glock rhashtable rcu bug
    - Add "shutdown" to "struct class".
    - tpm: Issue a TPM2_Shutdown for TPM2 devices.
    - tpm: fix a kernel memory leak in tpm-sysfs.c
    - [x86] uaccess: Optimize copy_user_enhanced_fast_string() for short strings
    - xen: avoid deadlock in xenbus driver
    - crypto: drbg - Fixes panic in wait_for_completion call
    - [x86] rt286: add Thinkpad Helix 2 to force_combo_jack_table
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.11
    - mqueue: fix a use-after-free in sys_mq_notify() (CVE-2017-11176)
    - proc: Fix proc_sys_prune_dcache to hold a sb reference
    - locking/rwsem-spinlock: Fix EINTR branch in __down_write_common()
    - [x86] staging: comedi: fix clean-up of comedi_class in comedi_init()
    - crypto: rsa-pkcs1pad - use constant time memory comparison for MACs
    - ext4: check return value of kstrtoull correctly in reserved_clusters_store
    - [x86] mm/pat: Don't report PAT on CPUs that don't support it

  [ Ben Hutchings ]
  * [m68k] udeb: Use only the common module list for nic-shared-modules
    (fixes FTBFS)
  * [sparc64] Update "Revert "sparc: move exports to definitions"" for the
    addition of __multi3 (fixes FTBFS)
  * binfmt_elf: use ELF_ET_DYN_BASE only for PIE (CVE-2017-1000370,
    CVE-2017-1000371)
  * [rt] Update to 4.11.9-rt7:
    - smp/hotplug: Move unparking of percpu threads to the control CPU
    - cpu_pm: replace raw_notifier to atomic_notifier
  * media: Enable MEDIA_CEC_SUPPORT, VIDEO_VIVID_CEC; USB_PULSE8_CEC as module
    (Closes: #868511)
  * [armhf] udeb: Add sunxi_wdt to kernel-image (Closes: #866130)
  * crypto: Enable CRYPTO_USER, CRYPTO_USER_API_RNG as modules (Closes: #868291)
  * udeb: Add dm-raid to md-modules (Closes: #868251)
  * [arm64] sound: Enable SND_HDA_INTEL as module (Closes: #867611)
  * aufs: Update support patchset to aufs4.11.7+-20170703 (Closes: #867257)
  * [x86] ideapad-laptop: Add various IdeaPad models to no_hw_rfkill list
    (Closes: #866706)
  * firmware: dmi: Add DMI_PRODUCT_FAMILY identification string
  * [x86] pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago
    systems (Closes: #862723)
  * [armhf] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
    (thanks to Guillaume Tucker) (Closes: #865646)

  [ Uwe Kleine-König ]
  * [arm64] enable FB_SIMPLE

  [ Vagrant Cascadian ]
  * [arm64] Enable support for Rockchip systems (Closes: #860976).

  [ Salvatore Bonaccorso ]
  * Bump ABI to 2
  * [rt] Update to 4.11.8-rt5

  [ Cyril Brulebois ]
  * [arm64,armhf] udeb: Ship usb3503 module in usb-modules, needed for
    e.g. Arndale development boards, thanks to Wei Liu (Closes: #865645).

[dgit import unpatched linux 4.11.11-1]

Import linux_4.11.11.orig.tar.xz

[dgit import orig linux_4.11.11.orig.tar.xz]

Import linux_4.11.11-1.debian.tar.xz

[dgit import tarball linux 4.11.11-1 linux_4.11.11-1.debian.tar.xz]